A system and method for secure proxy-based authentication

ABSTRACT

A system and method for secure authentication facilitates improving the security of authentication between a client and a target by using an innovative authentication module on a proxy. The client can connect to the proxy using a native protocol and provides client credentials to the proxy. The proxy uses an authentication module to authenticate the client and then to provide target access credentials for proxy-target authentication, thereby giving the client access to the target through the proxy. The invention facilitates connection between the client and the target without requiring the client to be in possession of the target access credentials. The proxy can optionally be connected to a privileged, access management system which can provide and/or store target access credentials. Proxy-provided target access credentials facilitate preventing a client security breech from exposing target access credentials.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of provisional patent application(PPA) Ser. No. 61/717,656, filed 24 Oct. 2012 by the present inventors,which is incorporated by reference.

FIELD OF THE INVENTION

The present invention generally relates to authentication, and inparticular, it concerns secure proxy-based authentication.

BACKGROUND OF THE INVENTION

Authentication is the process of verifying the identity of a person orapplication.

Authentication in computer systems can be done in various ways andinvolves acquiring user or application characteristics or credentialsand verifying them against a known value. In popular conventionalauthentication implementations, a user, which can be a person or anapplication, requesting a connection to a target will interact with aclient (machine) which then provides client credentials to the target.Typically, the target is a server machine or server process providing aservice to the client. Typically, direct connection is made to thetarget via a native protocol. The target (or server) can be implementedeither in hardware or by software. Upon receiving the clientcredentials, the target will authenticate the provided clientcredentials by comparing them with known values in order to verify theclient and accordingly authorize (grant or deny) the request forconnection. In this conventional authentication process, securitybreaches can occur at the client, at the target and in the transfer ofclient credentials between the client and the target (duringcommunications).

Various systems involving proxies attempt to address security issues inthe aforementioned authentication process: US2006/0101510 to Kadykdescribes a method for negotiating a secure end-to-end connectionbetween a client and a server where a proxy facilitates establishment ofthe end-to-end connection. In this method, a client initiallyestablishes a secure connection to the proxy via which the clientauthenticates to the proxy. Once the client is authenticated to theproxy, the connection between the client and proxy is downgraded to aninsecure connection. The proxy then facilitates establishment of asecure (encrypted) end-to-end connection between the client and theserver by forwarding a client system request to the server. The secureend-to-end connection is encapsulated within the insecure client-proxyconnection. This method, prevents client credentials from being exposedin the client-proxy communications link and allows the client tocommunicate with the target without the proxy being aware of thecommunications (the end-to-end connection is secured). Kadyk therebyteaches an end-to-end connection between the client and the serverwherein a conventional proxy forwards communications between client andserver. EP 1157344 to Hudson describes a proxy server including adatabase. The proxy uses the database to augment a client request byadding user profile information from the database to the received clientrequest. The proxy then sends the augmented client request, includingclient credentials, to the server for authentication. Hudson therebyteaches transfer of client requests including client credentials by aproxy wherein the original client request including the original clientcredentials are augmented by the proxy. There also exist other nativeprotocol systems for filtering connections or adding information at aproxy. However, such systems do not address the security issuesdescribed in this document.

US2006/0225132 to Swift describes a method of controlling access tonetwork services where an authorized proxy can access a service onbehalf of a user. In this method, only authorized proxies can accessservices. Swift thereby teaches access limitation to a server wherebyonly authorized conventional proxies can access network services.

US2011/0231651 to Bollay describes establishment of an encrypted sessionbetween a client and a proxy facilitating access to a target. Theaddress of the target server is only provided to the client once anencrypted client-proxy session is established. Bollay thereby teachesrestricting communication of a target server address whereincommunication of the target server address is only through encryptedclient-proxy sessions.

Conventional use of proxies for authentication of a client to a targetmeans that the client connects to the proxy via a special protocol ofthe application on the proxy providing the connection. This means thatthe client needs to change, for example, scripts, procedures,applications, etc. on the client in order to use the protocol of theproxy application.

Generally, in conventional authentication techniques, the authenticationcredentials are held by the client and are sent to the target forauthentication. Requiring the client to have credentials that will allowthe client to authenticate directly with the target means that if theclient is compromised (hacked, breached), the client credentials can behijacked and abused, providing access to the target. This risk ismanifested by the existence of a variety of attack tools that directlyfocus on credentials, including keyloggers that can capture typedpasswords, memory grabbers that can retrieve passwords from machinememory and many others.

Another security concern is due to the limitations of human users. Humanusers choose relatively simple, easy-to-remember passwords and often usethe same password for different needs. Thus, conventional authenticationsystems and methods using password-based credentials can be vulnerableto security threats due to low password complexity and password reuse.

Furthermore, in the context of shared or privileged accounts, forexample, when the same account is used by a group of administrators,conventional authentication systems are unable to link actions on atarget to an individual user. In other words, when a common accesscredential (such as user/password) is used by group of users, there isno attribution on the target for which user is using thecredentials/performing actions on the target machine.

Some systems attempt to address security issues by only allowingauthorized clients (e.g. US2011/0231651 to Bollay) or authorized proxies(e.g. US2006/0225132 to Swift) access to a target. Other solutionsattempt to improve security by using a proxy to establish a secureend-to-end connection between a client and a server. However, thesesolutions do not address the security issue of the client possessingcredentials that provide direct access to the target.

Other systems attempt to address issues of security, shared accounts,credentials replacement and monitoring by installation of a centralsystem, such as a proxy, which can be a ‘jump server’, through which aclient establishes sessions with a target. The client connects to theproxy either through a terminal or through a browser-based interface.The proxy then establishes a native session with the target, usingclient credentials. Proxy systems are typically more complex toimplement than conventional systems, including additional challengessuch as using non-native protocols for client-proxy communications.

There is, therefore, a need for a system and method for securelyauthenticating a client to a target, without target access credentialsbeing exposed and available on the client machine. Furthermore, there isa need for secure authentication of a client to a target whilstretaining the client access method.

SUMMARY

According to the teachings of the present embodiment there is provided amethod of authentication including the steps of: receiving at a proxy anaccess request, wherein the receiving is via a protocol and the accessrequest includes client credentials associated with a user; providingtarget access credentials, wherein the providing is based on the accessrequest, the client credentials, and target authentication information;and sending via the protocol the target access credentials to a target;wherein the target access credentials are other than the clientcredentials.

In an optional embodiment, the receiving is from a client.

In an optional embodiment, the providing is contingent on successfullyverifying the user based on the client credentials.

In an optional embodiment, the client credentials are selected from thegroup consisting of: a null set; and inherent client credentials.

In an optional embodiment, the providing of the target accesscredentials is based on one or more communication features selected fromthe group including: communication content; access request time, clientidentity, target identity, user identity; access request time;communication time; communication protocol; communication settings; andcombinations of the communication features.

In an optional embodiment, the target authentication information isprovided by: a database; or an algorithm; or a privileged accessmanagement system (PAMS).

In an optional embodiment, a privileged access management solution(PAMS) performs one or more steps selected from the group consisting ofauthenticating the client credentials; providing the target accesscredentials; storing monitoring information; storing analysisinformation; monitoring client communications from the client to thetarget; and monitoring target communications from the target to theclient.

In an optional embodiment, the method further includes the step of: ifthe target successfully verifies the target access credentials thenauthorizing communications between the client and the target via theproxy.

In an optional embodiment the method further includes: if the targetsuccessfully verifies the target access credentials then the proxytransferring client communications from the client to the target andtransferring target communications from the target to the client.

In another optional embodiment, the method further includes at leastone-step selected from the group consisting of: monitoring the clientcommunications and the target communications; recording the clientcommunications and the target communications.

In another optional embodiment, the monitoring and the recording are ofone or more communication features selected from the group consistingof: a communication content; a target identity; a client identity; auser identity; a communication time; communication protocol; andcommunication metadata.

In another optional embodiment, the method further includes the step of:upon detecting a suspicious activity, initiating an alert.

In another optional embodiment, the method further includes the step ofupon receiving an alert, terminating the transferring clientcommunications and terminating the transferring target communications.

In another optional embodiment, the method further includes one or moresteps selected from the group consisting of: interfering with the targetcommunications; and interfering with the client communications.

In another optional embodiment, the interfering is selected from atleast one of: deleting target communications; masking targetcommunications; replacing target communications; deleting clientcommunications; masking client communications; and replacing clientcommunications.

In another optional embodiment, the interfering is by at least one of awhite-list; a black-list; a replacement list; a client communicationtime; a client identity; a target identity; and a communication history.

In an optional embodiment, a form of the client credentials and a formof the target access credentials are each selected from the groupconsisting of username, password, access key, credential file, biometricidentifier, gesture, selecting an image, physical token, certificatesmachine or device identifier, application identifier and combinations offorms of credentials.

According to the teachings of the present embodiment there is provided asystem for authentication including: a proxy configured to: receive anaccess request, wherein the receiving is via a protocol and the accessrequest includes client credentials associated with a user; providetarget access credentials based on the access request, the clientcredentials and target authentication information; and send via theprotocol the target access credentials to a target; wherein the targetaccess credentials are other than the client credentials.

In an optional embodiment, the access request is received from a client.

In an optional embodiment, the system further includes a privilegedaccess management solution (PAMS) configured to perform one or morefunctions selected from the group consisting of: authenticating theclient credentials; providing the target access credentials; storingmonitoring information; storing analysis information; monitoring clientcommunications from the client to the target; and monitoring targetcommunications from the target to the client.

In an optional embodiment, the system further includes an analysismodule configured to initiate an alert based upon detecting a suspiciousactivity.

In an optional embodiment, the providing is contingent on successfullyverifying the user based on the client credentials.

In an optional embodiment, the client credentials are selected from thegroup consisting of: a null set; and inherent client credentials.

In an optional embodiment, the providing of the target accesscredentials is based on one or more communication features selected fromthe group including: communication content; access request time, clientidentity, target identity, user identity; access request time;communication time; communication protocol; communication settings; andcombinations of the communication features.

In an optional embodiment, the target authentication information isprovided by: a database; or an algorithm; or a privileged accessmanagement system (PAMS).

In an optional embodiment, a privileged access management solution(PAMS) performs one or more steps selected from the group consisting ofauthenticating the client credentials; providing the target accesscredentials; storing monitoring information; storing analysisinformation; monitoring client communications from the client to thetarget; and monitoring target communications from the target to theclient.

In an optional embodiment, the system further including the step of: ifthe target successfully verifies the target access credentials thenauthorizing communications between the client and the target via theproxy.

In an optional embodiment the system further includes: if the targetsuccessfully verifies the target access credentials then the proxytransferring client communications from the client to the target andtransferring target communications from the target to the client.

In another optional embodiment, the system further includes at leastone-step selected from the group consisting of: monitoring the clientcommunications and the target communications; recording the clientcommunications and the target communications.

In another optional embodiment, the monitoring and the recording are ofone or more communication features selected from the group consistingof: a communication content; a target identity; a client identity; auser identity; a communication time; communication protocol; andcommunication metadata.

In another optional embodiment, the system further includes the step of:upon detecting a suspicious activity, initiating an alert.

In another optional embodiment, the system further includes the step of:upon receiving an alert, terminating the transferring clientcommunications and terminating the transferring target communications.

In another optional embodiment, the system further includes one or moresteps selected from the group consisting of: interfering with the targetcommunications; and interfering with the client communications.

In another optional embodiment, the interfering is selected from atleast one of: deleting target communications; masking targetcommunications; replacing target communications; deleting clientcommunications; masking client communications; and replacing clientcommunications.

In another optional embodiment, the interfering is by at least one of: awhite-list; a black-list; a replacement list; a client communicationtime; a client identity; a target identity; and a communication history.

In an optional embodiment, a form of the client credentials and a formof the target access credentials are each selected from the groupconsisting of username, password, access key, credential file, biometricidentifier, gesture, selecting an image, physical token, certificatesmachine or device identifier, application identifier and combinations offorms of credentials.

According to the teachings of the present embodiment there is provided acomputer-readable storage medium having embedded thereoncomputer-readable code for authenticating, the computer-readable codeincluding program code for: receiving at a proxy an access request,wherein the receiving is via a protocol and the access request includesclient credentials associated with a user; providing target accesscredentials, wherein the providing is based on the access request, theclient credentials, and target authentication information; and sendingvia the protocol the target access credentials to a target; wherein thetarget access credentials are other than the client credentials.

According to the teachings of the present embodiment there is provided acomputer program that can be loaded onto a server connected through anetwork to a client computer, so that the server running the computerprogram constitutes a proxy in a system according to any one of theabove claims.

According to the teachings of the present embodiment there is provided acomputer program that can be loaded onto a computer connected through anetwork to a server, so that the computer running the computer programconstitutes a client computer in a system according to any one of theabove claims.

BRIEF DESCRIPTION OF FIGURES

The embodiment is herein described, by way of example only, withreference to the accompanying drawings, wherein:

FIG. 1A is a schematic diagram of a conventional system ofauthentication, which does not include a proxy, wherein a clientdirectly authenticates to a target.

FIG. 1B is a schematic diagram of a conventional system ofauthentication including a proxy.

FIG. 2 is a schematic diagram of an exemplary implementation of anauthentication system.

FIG. 3 is a high-level partial block diagram of an exemplary systemconfigured to implement proxy of the present invention.

FIG. 4 is a schematic diagram of a conventional system of authenticationincluding a proxy or jump server.

FIG. 5 is a schematic diagram of another conventional system ofauthentication including a proxy.

FIG. 6 is a schematic diagram of an another conventional system ofauthentication similar to that illustrated in FIG. 1B.

FIG. 7 is a schematic diagram of an another conventional system ofauthentication similar to that illustrated in FIG. 5

DETAILED DESCRIPTION—FIGS. 1-7

The principles and operation of the system and method according to apresent embodiment may be better understood with reference to thedrawings and the accompanying description. A present invention is asystem and method for secure authentication. The invention facilitatesimproving the security of authentication between a client and a targetby using an innovative authentication module on a proxy. The client canconnect to the proxy using a native protocol and provides clientcredentials to the proxy. The proxy uses an authentication module toauthenticate the client and then to provide target access credentialsfor proxy-target authentication, thereby giving the client access to thetarget through the proxy. The invention facilitates connection betweenthe client and the target without requiring the client to be inpossession of the target access credentials. As will be described inmore detail below, proxy-provided target access credentials facilitatepreventing a client security breech from exposing target accesscredentials.

Credentials are provided (passed, sent, or transmitted) to anauthentication element or module of a system and evaluated during anauthentication process. The credentials are verified by theauthentication module against data known to the authentication moduleand then, if the verification is successful the credentials areauthenticated and the authentication module authorizes access to theelement or system. While a popular form of credentials is username andpassword, forms of credentials also include access keys, credentialfiles, gestures, biometrics, selecting an image, physical tokens,certificates, machine or device identifier, application identifier andother forms of credentials used for authentication, and combinations offorms of credentials as known in the art.

The term ‘authentication’ or ‘authenticating’ in the context of thisdocument generally refers to the process of verifying the identity of aperson or application. This process can include receiving credentials ofthe person or application, comparing them with known values, andaccordingly verifying (successfully or unsuccessfully) the identity ofthe person or application.

The term ‘authorization’ or ‘authorizing’ in the context of thisdocument generally refers to the process of granting or denying accessor a level of access to a target system to a person or application thathas been authenticated.

The term ‘client credentials’ in the context of this document generallyrefers to credentials possessed by the client which can be used toverify that a client is who the client claims to be. Client credentialscan be used in authentication with another element or module of asystem, for example in a direct authentication to a target or inauthentication to a proxy.

The term ‘target access credentials’ or simply ‘target credentials’ inthe context of this document generally refers to credentials forauthentication to a target. Target credentials can be passed to thetarget by another element or module of a system, for example by a proxyor by a client.

In conventional authentication, where a client directly authenticates toa target, typically client credentials and target credentials are thesame.

The term ‘credentials’, when used in general in this document, can referto any credentials in the system, including client credentials andtarget credentials.

In the context of this document, the term ‘user’ is generally used torefer to a human who is interacting with a client, but can also refer toan application on the client machine, to a machine or device connectedto the client machine (such as mobile or network device), and to amachine or device, such as a piece of hardware (where the hardware isacting as the user). One skilled in the art will realize from thecontext of the description in this document that the term “user” mayalso refer to an application on a client.

In the context of this document, the tem) ‘client’ or ‘client machine’generally refers to the machine, device, or module used by a user(human, application, or machine). For example, an application (user) canreside on a client machine. Actions performed by a user are typicallyperformed on the client (client machine). As will be obvious to oneskilled in the art, the use of the general term ‘client’ refers to aportion of the system including the client machine and/or an associateduser, user actions, and/or client processes The term ‘client’ when usedin connection with actions or processes of the system can refer to useractions and/or client machine processes.

The term ‘proxy’ in the context of this document generally refers to amachine, module, application, or system that acts as an intermediary forrequests between clients and target/s.

Th term ‘target’ in the context of this document generally refers to amachine, module, application, or system that provides service to aclient. Typically, a client desires connection with a target, and theclient initiates connecting between the client and the target.

The term ‘client communications’ in the context of this documentgenerally refers to communications originating at and from the client.

The term ‘target communications’ in the context of this documentgenerally refers to communications originating at and from the target.For clarity in the current document, functionality of client, proxy andtarget are each shown on a separate machine. As is known in the art,alternative implementations are possible. For example, implementing oneor more of the client, proxy, and target as configurable modules on oneor more processing systems.

The term ‘machine’ in the context of this document is used forsimplicity and clarity and should not be interpreted as limitingimplementation of the current invention. As will be obvious to oneskilled in the art, the term machine can include computers and computingsystems (for example, physically separate locations or devices) andprocessors, processing systems, computing cores (for example, shareddevices) and similar systems, modules, and combinations on whichimplementations can be instantiated. In general, a machine is anexecution environment for computer software, including a physical orvirtual hardware environment and an operating system.

In the context of this document the term ‘link’ is generally used torefer to a communications path between two elements/modules of thesystem e.g. a client-proxy link, a target-proxy link. Each link in asystem can be physically the same or different. For simplicity in thecurrent description, a link is generally between two modules over anetwork. For example, a link can be a TCP/IP connection. As will beknown to one skilled in the art, each link in the system may use eithercommon or different physical means of implementation, including, but notlimited to TCP/IP sessions on the same network, physically separatecomputer networks, different types of network (for example, Ethernet orcellular), and common infrastructures with logical separation (forexample, a common Ethernet network with more than one VLAN (virtuallocal area network) implementing the links).

In the context of this document ‘logical communications link’ isgenerally used to refer to a communications path over which informationcan flow between two elements/modules of the system formed by linksand/or element/s between them.

In the context of this document the terms ‘communication’ and‘communications’ are generally used to refer to transfer of information.For example, between clients, proxies, and servers, including but notlimited to commands, actions, transfer of data, etc.

In the context of this document, the term ‘communication feature’ isgenerally used to refer to a parameter or characteristic of acommunication. Communication features include but are not limited to,communication content, target identity, client identity, user identity,access request time, communication time, communication protocol, andcommunication metadata. Communication content is the data content of thecommunication i.e. credentials (client or target), a command, an action,or data to be transferred. Target identity, client identity and useridentity are data able to identify the target, client, or userassociated with a communication, for example, the IP (Internet Protocol)address. Communication time can be the time of sending or time ofreceipt of the communication. Communication protocol is the protocol bywhich a communication is sent. Communication metadata includesparameters describing the communication, such as source IP, destinationIP, source port, destination type of protocol being used, time etc.

In the context of this document, the term ‘native protocol’ is used todenote an existing conventional protocol that is used to communicatewith a specific target. For example, a native protocol can be SSH(Secure Shell) protocol, which is commonly used to connect to UNIXmachines. Many other protocols are known, whether public or proprietary,such as SQL (Structured Query Language), FTP (File Transfer Protocol),HTTP (Hypertext Transfer Protocol), HTTPS (Hypertext Transfer Protocol.Secure), etc. Native protocols are generally level 4 (L4) of the OSI(Open Systems Interconnection) model, however they can be of analternative level (e.g. HTTP).

For Windows servers, a common native protocol is RDP (Remote DesktopProtocol). It should be noted, that RDP is a special case of a nativeprotocol, as it often serves as a non-native protocol as well, toconnect to a jump-server or proxy (see below).

In networks that employ proxy or jump-server architecture, a non-nativeprotocol is a protocol that is used for client to proxy communication,while the communication between the proxy and the target is done by anative protocol. Non-native protocols focus on transferring usercommands to the proxy and commands are sent by the proxy to the targetthrough the native protocol. Examples of non-native protocols are can bebrowser based interactive protocols including RDP, RFB (Remote FrameBuffer) protocol, Citrix protocol etc.

Referring now to the drawings, FIG. 1A is a schematic diagram of aconventional system of authentication, which does not include a proxy,wherein a client 100 directly authenticates to a target 104. Client 100is in possession of client credentials 130. In this case, clientcredentials 130 also function as target access credentials. When client100 wants to access target 104, client 100 sends an access request 106to target 104 via client-target link 119 using a native protocol. Accessrequest 106 includes client credentials 130. Target 104 receives accessrequest 106 and performs authentication using client credentials 130. Ifclient credentials 130 are verified and authentication is successful,target 104 authorizes establishment of a client-target logicalcommunications link 124 between client 100 and target 104.

Referring to FIG. 1B, a schematic diagram of a conventional system ofauthentication including a proxy 102. Implementation of conventionalproxies is known in the art, and includes products such as jump servers.A jump-server is a special purpose component or module generally usedfor managing devices in a separate security zone. As in the case of FIG.1A, client credentials 130 function as both client credentials andtarget access credentials. Client 100 and target 104 communicate viaproxy 102. Client 100 is in possession of client credentials 130. In atypical case, when client 100 wants to access target 104, client 100sends a first access request 107 to proxy 102 via a client-proxy link120 using a non-native protocol. First access request 107 includesclient credentials 130. Proxy 102 then sends a second access request 108using a native protocol to target 104 via a target-proxy link 122.Second access request 108 can be the same as first access request 107 orcan be modified by proxy 102. In either case, a feature of conventionalsecond access request 108 is the inclusion of client credentials 130.Target 104 receives second access request 108 and performsauthentication using client credentials 130. If target 104 successfullyverifies client credentials 130 and authentication is successful, target104 authorizes establishment of a client-target logical communicationslink 124 between client 100 and target 104.

Referring to FIG. 6, a schematic diagram of another conventional systemof authentication similar to that illustrated in FIG. 1B. In this systemclient 100 is in possession of a first client credentials 130 and asecond client credentials 630. Client 100 uses first client credentials130 to establish the client-proxy connection, and client 100 thentransmits a second client credentials 630 to establish the connectionbetween proxy 102 and target 104. In this case, both credentials 130 and630 are sent from the client 100. The system illustrated by FIG. 6 canbe implemented using, for example, systems offered by Citrix®.

Referring to FIG. 5, a schematic diagram of another conventional systemof authentication including a proxy 102. In this system, a client 100sends requests to proxy 102 using a native protocol. Client credentials130 function as both client credentials and target access credentials.Client 100 and target 104 communicate via proxy 102. Client 100 is inpossession of client credentials 130. In a typical case, when client 100wants to access target 104, client 100 sends a first access request 107to proxy 102 via a client-proxy link 120 using a native protocol. Firstaccess request 107 includes client credentials 130. Proxy 102 then sendsa second access request 108 using a native protocol to target 104 via atarget-proxy link 122. Second access request 108 can be the same asfirst access request 107 or can be modified by proxy 102. In eithercase, a feature of conventional second access request 108 is theinclusion of client credentials 130. Target 104 receives second accessrequest 108 and performs authentication using client credentials 130. Iftarget 104 successfully verifies client credentials 130 andauthentication is successful, target 104 authorizes second accessrequest 108 and communications between client 100 and target 104 areestablished via proxy 102. Communications between client 100 and target104 are via two links: a proxy-client native protocol logicalcommunications link 204 and a proxy-target native protocol logicalcommunications link 207.

Referring to FIG. 7, a schematic diagram of another conventional systemof authentication similar to that illustrated in FIG. 5. In this systemclient 100 is in possession of a first client credentials 130 and asecond client credentials 630. Client 100 uses first client credentials130 to establish the client-proxy connection, and client 100 thentransmits a second client credentials 630 to establish the connectionbetween proxy 102 and target 104. In this case, both credentials 130 and630 are sent from the client 100.

Existing conventional systems of client authentication, including thesystems illustrated in FIG. 1A, FIG. 1B, and FIG. 5 have a number ofsecurity issues:

In both the conventional systems of FIG. 1A, FIG. 1B, FIG. 5, FIG. 6,and FIG. 7 the client is in possession of target access credentials,whether they are the same as client credentials used to communicate tothe proxy or a separate set of credentials, and therefore the client canaccess the target. If the client is compromised (hacked, breached), thetarget access credentials can be hijacked and abused, providing accessto the target system. For example, an attacker can use software thatcaptures keystrokes for hijacking username/password combinations or canextract security information e.g. access keys or credentials files fromclient applications.

Existing authentication systems, in the case of a human client usingpassword-based authentication, have security issues due to limitationsof ‘simple’ passwords, such as password complexity and password reuse.Simple passwords chosen by a human client are often of a low complexity,tend to be short in length, use characters from a limited character set,and use words and formats that are easier to find in comparison with‘complex’ passwords, such as a random or pseudo-random password of asimilar length. Such simple passwords provide lesser protection fromvarious security attacks, such as brute forcing where an attacker triesmultiple passwords, in comparison to complex passwords. Although complexpasswords are more secure, using complex passwords is difficult toimplement with human clients as complex passwords are more difficult toremember and use as compared to simple passwords. Additionally, humanclients, as users generally need to remember and use a number ofpasswords, will often reuse the same password for multiple targetsystems meaning that a compromise of one target system can compromiseanother. In general, password reuse includes various types ofcredentials reuse. In a case where client credentials allow a user toaccess a target, the client credentials are the target credentials, andreuse and/or compromise of client credentials includes similar problemsto password reuse. Different, unique passwords for every target systemare more secure, but are much more difficult for a user to remember andimplement.

An additional issue in conventional authentication methods is a lack ofaction-accountability in shared account or shared identity situations.Frequently, more than one user can access a target using the same targetcredentials. This is particularly true in the case of accountsrepresenting a role on the target system, such as administrator, system,technician, application, etc. In these cases authentication to thesystem of more than one individual client or user is with a sharedaccount, using the same target credentials, meaning actions performed onthe system cannot be linked to a particular client or user. This isparticularly problematic as these shared accounts are often alsoprivileged accounts enabling performance of actions on the target systemthat require specific privileges.

As illustrated in FIG. 1B, the conventional introduction of a proxy forauthentication of a client to a target means that the client connects tothe proxy via a non-native protocol. In other words, instead of using anative-protocol as described in reference to FIG. 1A, the client of FIG.1B must be changed to use a special, non-native protocol to communicatewith the proxy (proxy application) providing the connection. This meansthat, upon introduction of a proxy to a system, the client needs tochange, for example, scripts, procedures, applications, etc. in order touse the protocol of the proxy application.

Refer now to FIG. 4, a schematic diagram of a conventional system ofauthentication including a proxy or jump server 402. An example ofsimilar proxy or jump servers is the Privileged Session Manager® offeredby CyberArk®. In this case, the proxy (or jump server) has access to acredentials repository 400 through a proxy-credentials repository link404. In a typical case, when client 100 wants to access target 104,client 100 connects with proxy (jump server) 402 via a client-proxy link120. Client-proxy link 120 is a terminal connection or browser-basedconnection and thus communication between client 100 and proxy 402 isvia non-native protocol/s. Client 100 sends a first access request 107that includes client credentials 130 via a non-native protocol. Onceproxy 402 has verified client 100 based on client credentials 130, proxy402 then receives target access credentials 232 from credentialsrepository 400 and sends a second access request 408 using a nativeprotocol to target 104 via a target-proxy link 122. Second accessrequest 408 includes target access credentials 232. Target 104 receivessecond access request 408 and performs authentication using targetaccess credentials 232. If target 104 successfully verifies targetaccess credentials 232 and authentication is successful, target 104authorizes second access request 108 and communications between client100 and target 104 are established via proxy 402. Communications betweenclient 100 and target 104 are via two links: a proxy-client non-nativeprotocol logical communications link 204 and a proxy-target nativeprotocol logical communications link 207.

In systems such as that of FIG. 4, as the client connects to the proxyvia a terminal or browser link, the connection uses a special protocolof the jump server application on the proxy. In other words, the clientproxy link 120 is a non-native protocol. Therefore, by introducing aproxy the client is then required to change the protocol by which theclient requests access to the target. This creates an implementationchallenge, since many users, especially privileged users such asadministrators or operators, do not want to use a terminal or a browserto connect to target machines.

Although in some conventional systems of authentication including aproxy, such as that illustrated in FIG. 5, the client connects to theproxy using a native protocol, in such systems the target accesscredentials are supplied by the client and therefore are not secured.

Referring again to the drawings, FIG. 2 is a schematic diagram of anexemplary implementation of an authentication system. In general, thisembodiment involves a client 100, a proxy 202, and a target 104. Client100 provides client credentials 130. When client 100 wants to accesstarget 104, client 100 sends a first access request 206 via a nativeprotocol to proxy 202. First access request 206 includes clientcredentials 130 and sufficient information for proxy 202 to be able toidentify target 104. In some embodiments client credentials 130 can beinherent credentials, contained in the access request, for exampleclient IP address. Proxy 202 includes an innovative authenticationmodule 203 and target authentication information 230.

Authentication module 203 authenticates the client using clientcredentials 130 and provides, using target authentication information230 and first access request 206, target access credentials 232. In oneembodiment upon verifying client credentials 130 authentication module203 provides target access credentials. Proxy 202 sends a second accessrequest 208 via a native protocol to target 104. Second access request208 includes target access credentials 232. Target 104 receives secondaccess request 208 and performs authentication using target accesscredentials 232. If target 104 successfully verifies target accesscredentials 232 and authentication is successful, target 104 authorizessecond access request 208 and communications between client 100 andtarget 104 are established via proxy 202. A feature of the currentembodiment is that communications between client 100 and target 104 arevia two links: a proxy-client native protocol logical communicationslink 204 and a proxy-target native protocol logical communications link207. In one embodiment target credentials 232 are privileged accountcredentials, for example administrative or root account credentials. Asclient 100 is not authenticated directly to the target 104 and does notpossess target credentials 232, communication between client 100 andtarget 104 including client communications originating from the clientand target communications originating at the target must be throughproxy 202. As a result, proxy 202 can have full knowledge of thecommunications between client 100 and target 104. Another significantfeature of the current embodiment is that the client 100 can connect tothe proxy 202 using the same (native) protocol the client originallyused in a conventional implementation to connect to target 104. In otherwords, the client is not required to go through a terminal/browser orother “non-native” protocols to authenticate to a target.

For clarity in FIG. 2, client credentials 130 are shown on client 100and target authentication information 230 is shown on proxy 202. Inanother embodiment, target authentication information 230 is a databaseable to provide target access credentials 232 based on an input, or twoor more inputs including, but not restricted to, client credentials 130,first access request time, first access request date, client identity,user identity, target identity, etc. In another embodiment, targetauthentication information 230 is provided by an algorithm able totransform input/s (e.g. client credentials 130) into target accesscredentials 232. Target authentication information 230 can be held bythe proxy (as shown) or alternatively by the authentication module or bya PAMS. Typically, target access credentials 232 are provided based oncommunications features of 206.

Note that target authentication information 230 can be implemented inmany forms, some typical examples of which are described above. Inaddition to target authentication information 230 being credentials, orbeing credentials provided by an algorithm, target authenticationinformation 230 can be logic that is, target authentication information230 is logic, the algorithm of which contains what is necessary toprovide target access credentials 232 based on a first access request206.

In an embodiment where PAMS 209 stores target access credentials 232target authentication information 230 is a logic request which indicatesto the PAMS what data to provide to target 204 as target credentials232.

Target access credentials 232 can come from a privileged accessmanagement system (PAMS) 209. PAMS 209 uses first access request 206 andtarget authentication information 230 to provide target accesscredentials 232. In some embodiments, target access credentials 232 arestored in PAMS 209. In yet another embodiment, the authentication module203 involves PAMS 209 both in authenticating the client using clientcredentials 130 and in providing target access credentials 232.

One skilled in the art will realize that credentials can be implementedin various forms, depending on the specific application. Depending onthe faun of credentials used, credentials may be stored on theclient/proxy, provided by a user to the client/application as needed, oraccessed from a machine other than the client/proxy. Based on thisdescription, one skilled in the art will be able to design credentialstorage and provisioning for a specific application (implementation).

Although in the figures only one client and one target are illustratedfor simplicity and clarity, one skilled in the art will realize that,typically, more than one client can concurrently or sequentially obtainaccess to one or more targets through one or more proxies.Interconnected systems including one or more than one client, one ormore than one proxy, and one or more than one target are envisioned andencompassed by the invention.

Although, in the illustrated embodiments, the system involves a clientaccessing a target, one skilled in the art will realize that suitableapplications of the invention include, but are not restricted to aclient-server relationship where target 104 is a server.

In an embodiment where the client is an application residing on a clientmachine, client-proxy authentication can be by inherent clientcredentials such as connection time and network address.

In another embodiment, client 100, proxy 202 and target 104 are all partof a single organization infrastructure. Client 100, proxy 202, andtarget 104 can be in the same physical location or geographicallyseparate. In another embodiment of the invention client 100 and target104 can be part of different organizational structures, for example, acustomer-provider relationship. If client 100 and target 104 are part ofdifferent organizational structures proxy 202 can be associated eitherwith client 100 or alternatively with target 104.

In another embodiment, proxy 202 is in combination with a server, whichcan be a virtual or physical server, on which a proxy applicationresides. Alternatively, proxy 202 can be an application residing on theclient machine or device or on another machine or device in the network.

It is important to note that the above-described embodiment of FIG. 2,unlike in the conventional proxy-based authentication systemsexemplified in FIG. 1A, FIG. 1B and FIG. 5, client credentials 130 areother than target access credentials 232. Therefore, the client is notexposed to the target access credentials, as the target accesscredentials are provided at the proxy. This prevents target accesscredentials from residing in client/user space, a significant feature ofthe current embodiment. Thus, an attack on the client cannot revealtarget access credentials providing access to the target. Furthermore,unlike the conventional authentication system of FIG. 4 connection ofthe client to the proxy is via native protocol/s. This makes the systemeasily implementable as clients can continue to use the same protocol toaccess the proxy as was previously used to access directly a target uponinstallation of the system.

Another feature of the current embodiment is that security issuesassociated with human clients, such as the above-described simplepasswords, password reuse, etc. can be avoided. This is as target accesscredentials 232 are provided by authentication module 203. As targetaccess credentials do not need to be remembered by a human, unique,complex passwords that can be updated frequently can be used. A furtherfeature is allowing a user to establish a connection to a target usingclient credentials of a different type than that supported by thetarget; the client credentials can be a different credentials type thanthe target access credentials. For example, a user accesses client 100using a prescribed form of authentication, such as a physical token.This authentication of the user to the client is the basis of clientcredentials 1.30. The user then initiates first access request 206. Onproxy 202, authentication module 203 processes request 206 (includingclient credentials 130) in combination with authentication information230 to generate second access request 208. In this example, targetaccess credentials 232 can include credentials that are alternativesand/or stronger than the credentials used by the user on the client,such as a complex password or a single use password. Thus, for example,a user can effectively establish a connection to a target through aproxy by employing a physical token, when the target only supports asingle-use password.

In some embodiments, as will be described below, shared/privilegedaccounts on a target can be accessed without divulging privileged targetaccess credentials to users and issues associated with control andmonitoring of shared or privileged accounts can be addressed. Inaddition, native protocols are used for all communication links,facilitating changes (such as the addition of valid credentials) on theprotocol level, avoiding the need for creating a separate session. Theuse of native protocols allows an increased level of control over thecontent of client-target communications, as compared to conventionalsolutions.

In an optional embodiment of the invention, the system further includesa privileged access management system (PAMS) 209. Privileged AccessManagement Systems (PAMS) are a well-known solution for managingprivileged accounts. These systems hold the credentials for privilegedaccounts and a mapping of users (usually administrators) to permittedaccounts, according to a policy defined by the organization. Theprivileged access management system 209 connects to authenticationmodule 203 at a privileged access management system input/output port210 and can manage target authentication information 230, privileged,shared, and other sensitive account target access credentials 232 in anorganizational infrastructure. Management by privileged accessmanagement system can include secure storage of credentials (includingclient credentials and/or target access credentials), management ofcredentials replacement, auditing, and other functions. An importantaspect of PAMS is the support of various workflows, such as managerialapproval for password retrieval, correlation with ticketing systems,password replacement and so on. These support organizational policy andprocedures for network security and access control.

Target access credentials 232 can be securely stored in a privilegedaccess management system secure storage 209. PAMSs are commerciallyavailable from a number of vendors. An example of a suitable securestorage is a PAMS solution by CyberArk® known as PIM/PSM suite, whichemploys Digital Vault solution as disclosed in U.S. Pat. No. 6,356,941.The privileged access management system manages target accesscredentials replacement, the changing or refreshing of target accesscredentials. This can be automated and involves changing target accesscredentials within the privileged access management system securestorage and communicating these new target access credentials to thetarget or targets. As mentioned previously, target access credentialsreplacement can be on a frequent basis, e.g. once a day. Although PAMStypically includes an internal user interface, privileged accessmanagement system input/output port 210 can alternatively connect to auser interface 212 (as illustrated). Both PAMS internal user interfaceand user interface 212 can provide external control to the privilegedaccess management system database and settings.

Optionally, embodiments of the invention can include one or moreoptional modules 214 with corresponding optional module input/outputport(s) 216. Optional module input/output port(s) 216 can connect tooptional user interface 212, providing external control through the userinterface to the functions of the optional modules. Optional moduleinput/output port(s) 216 can connect to other elements of the system asnecessary. One skilled in the art will realize that optional modules canbe implemented as part of other elements of the system, for example aspart of the privileged access management system, or implementedstand-alone. For simplicity in the current description, a distinction isgenerally not made, for example, if a monitoring module is stand-aloneor part of the privileged access management system.

In an optional embodiment, optional modules 214 includes a usage policymodule that can implement a usage policy. For example, the usage policymodule can specify which clients have access to which targets, allowedaccess times, and/or dates for each client-target pair, andcommunication settings e.g. allowed protocols for each client-targetpair etc. Access times can be categorized by an access request time thatcan be the time of sending or receiving a first or second accessrequest.

In another embodiment, optional module 214 includes a database thatcontains necessary information for the aforementioned features,including for each client-target pair such information as: if access isallowed, allowed times/dates, and allowed protocols.

In other optional and/or additional embodiments, the optional modules214 can provide features including filtering, action control,monitoring, analysis, recording, attribution, interference, andtermination.

In an optional embodiment, optional modules 214 includes a filteringmodule. The filtering module filters communications to and from thetarget system.

The filtering module can implement a variety of control depending on thespecific application. Implementations of a filtering module include, butare not restricted to access or action control; limiting access to atarget and limit or control of actions performed on the target. Sinceall client communications and all target communications go through theproxy, the proxy is able to interfere with all communications, includingcommands that are sent from the client to the target. The filteringmodule can correlate client communications with a preconfigured policyfor the specific account being used and enforce action limits. Methodsof filtering or interfering with client commands in accordance with apredefined list are known in the art.

A suitable filtering or interference method is white-listing orblacklisting specific commands. White listing refers to enablingspecific commands on a target according to a preset white list,blacklisting refers to preventing specific commands on a targetaccording to a preset black-list. More complex filtering is alsoimplementable such as permitting specific commands only at specifictimes, and/or only from specific originating IP addresses (clients),and/or only in a specific order, and/or only to specific targets, and/oronly between specific client-target pairs etc. Such complex filtering isthus by communication time, and/or a client identity and/or a targetidentity, and/or a communication history where a communication historyis a historic sequence of communications for a given time duration ornumber of communications or number of commands.

Target communications (communication or output from a target) can alsobe filtered according to a predefined policy as is known in the art. Forexample, it is possible to delete specific data for example, the outputof specific commands. It is possible to mask specific data, preventingthe client from viewing/having access to the specific data, for example,internal IP addresses. It is possible to replace specific data. Suchdeleting, masking, and replacing actions can each be according to apreset list, a deletion list, a masking list, and a replacement list.

When the client has the credentials for multiple targets, monitoring andanalysis of client communications in conventional authentication systemsbecomes challenging, since multiple monitoring agents must be installedon all targets or all clients. The introduction of proxy 202 addressesthis challenge as proxy 202 provides a central point on which monitoringcan be successfully performed. In one embodiment, optional modules 214includes a monitoring module that facilitates proxy-based monitoring ofcommunications between the client 100 and the target 104. Basicmonitoring may include storing all communications between the client andthe proxy and between the proxy and the target. Another form ofmonitoring is to store the communication content, for example the actualcommands being sent in these communications. Monitoring can be automaticwhen communications between a client and a target are initiated.Monitoring can include analyzing certain communications resulting in themonitoring module producing a monitoring signal. For example, a databaseof possible communications can be associated with the monitoring module,and monitoring can be implemented at least in part by comparing clienttarget communication against this database. A monitoring signal can beproduced according to the database or data list. The monitoring signalcan be used for logging activity, or notifying one or more entities, inparticular initiating an alarm or alert to notifying a systemadministrator or other entity upon detection of suspicious ornon-permitted activity. For example, when a user or client attempts toconnect to a target outside of an allowed access window, repeatedattempts from a client to connect to a target, or requests fromunauthorized users to access a particular target.

In one embodiment, the monitoring module inspects client communicationsand target communications using a rule based method where specificactions that are deemed sensitive or potentially dangerous by theorganization are described in a predefined behavior policy and themonitoring module initiates an alert or alert signal when acommunication matches a rule.

In another embodiment, the monitoring module inspects client-target andtarget-client communications using a statistical based method where themonitoring module learns normal behavior patterns and detects anomaliesor deviations from normal behavior,

Alternatively, monitoring can be manual where a human views thecommunications through user interface 212 or in an embodiment whereclient communications and/or target communications are replicated to aseparate server for viewing and analysis.

Optional modules 214 can include a control module. The control modulecan modify communications and terminate the connection between theclient and the target system. The term ‘modify’ in this context refersto the content of the communication being altered. This can also betermed ‘replacement’ or ‘replacing’ because the original communicationis replaced by a modified version. Control can be automatic, where setsituations or commands result in a particular interference. Control canalso be manual, where a human monitoring the communications through theuser interface can respond by modifying a communication or terminatingthe connection between the client and target.

Optional modules 214 can include a recording module which can record orlog to a recording storage (not shown) various features of (informationregarding) communications between the client and target. Recordablecommunications features include information such as the content of thecommunication, the client identity, the target identity, the useridentity, the communication time and date, the communication protocoletc. One or more recordable features can be recorded together for easeof data retrieval. The recording module can provide audit information,facilitating auditing of communications where a user accesses therecording storage through a user interface, auditing part or all of thecontents. Monitoring, as described above, can also be employed inrecording where the system can monitor in order to define or decidewhich communications or features of communications should be recorded.

As the proxy is aware of which client is accessing which target and thecontent of the communications between the client and the target via theproxy, in one embodiment the authentication module and/or optionalmodules such as monitoring module, control module, or

PAMS can provide attribution, where communications with (andparticularly commands to) a target can be linked to a particular client.This is particularly useful as conventional systems have difficulty inattribution to a particular client or user on shared identity accounts.

In embodiments were attribution is achieved by integration with PAMS209, PAMS 209 can provide user authentication and target credentials, asdescribed above. In such embodiment, PAMS holds the records regardingwhich user accessed which target with what credentials, records that areneeded for attribution.

The proxy authentication module and privileged access management systemmodule can both be implemented in hardware, firmware, software, or anycombination thereof. The privileged access management system can beimplemented as a stand-alone module in communication with theauthentication module, or implemented as a sub-module in theauthentication module.

A method of authentication includes the steps of receiving at a proxy anaccess request via a protocol. The access request includes clientcredentials associated with a user. After the proxy receives the accessrequest, the proxy provides target access credentials for authenticatingthe user. Providing the target access credentials is based on the clientcredentials and target authentication information. The provided targetaccess credentials are then sent by the proxy via the same protocol to atarget. A significant feature of this embodiment is that the targetaccess credentials provided by the proxy are other than the clientcredentials.

FIG. 3 is a high-level partial block diagram of an exemplary system 300configured to implement proxy 202 of the present invention. System(processing system) 300 includes a processor 302 (one or more) and fourexemplary memory devices: a RAM 304, a boot ROM 306, a mass storagedevice (hard disk) 308, and a flash memory 310, all communicating via acommon bus 312. A module (processing module) 314 is shown on massstorage 308, but as will be obvious to one skilled in the art, could belocated on any of the memory devices.

Mass storage device 308 is a non-limiting example of a computer-readablestorage medium bearing computer-readable code for implementing theauthentication methodology described herein. Other examples of suchcomputer-readable storage media include read-only memories such as CDsbearing such code.

System 300 may have an operating system stored on the memory devices,the ROM may include boot code for the system, and the processor may beconfigured for executing the boot code to load the operating system toRAM 304, executing the operating system to copy computer-readable codeto RAM 304 and execute the code.

Network connection 320 provides communications to and from system 300.Typically, a single network connection provides one or more links,including virtual connections, to other devices on local and/or remotenetworks. Alternatively, network connection 320 can provide system 300with more than one network connection (not shown), each networkconnection providing one or more links to other devices and/or networks.

For clarity, non-limiting examples of operation of the currentembodiment are now described: In a first non-limiting example, theclient is an application and needs to connect to a target database. Theapplication connects to the proxy, sending a first access request via anative protocol connection e.g. by using SQL (Structured QueryLanguage), which includes the application's credentials. Anauthentication module on the proxy authenticates the application byusing the application's credentials, connection time, and the networkaddress from which the request originated. The proxy then establishes atarget-proxy link via the native protocol connection e.g. by using SQL,to the target database on the target. The authentication module injectsthe correct target access credentials into the first access request tocreate a second access request. The second access request is transmittedvia the target-proxy link to the target that authenticates the secondaccess request using the target access credentials, and if positive,authorizes access to the target database. These sensitive target accesscredentials are not divulged to the client application and do not reacha machine on which the application resides. Thus, for example,preventing an attacker that has breached the client machine fromextracting and abusing the sensitive target access credentials. Allcommunications and actions between the client application and the targetsystem are monitored by the privileged access management system (forexample for an integrated or stand-alone monitoring module) and can beattributed to the specific application.

In a second non-limiting example, a user that is a system administratorwants to establish a connection using a “root” account to a target UNIXmachine. From the system administrator's personal computer, acting asthe client, the system administrator establishes a native protocolconnection (such as SSH) to the proxy system. The system administratorinitiates a first access request to authenticate to the proxy with apersonal user identifier. The proxy system via the authentication moduleverifies that the system administrator has access rights to the targetUNIX machine. The proxy system (authentication module) then generates asecond access request to the target. The proxy establishes a connectionto the target system. The “root” account target access credentials arenot divulged to the user, in this case, the system administrator, andnever reach the client machine. All actions are also monitored and canbe attributed to the specific user. In a case where multiple people areacting as a system administrator for the target, the current embodimentallows multiple users to be authenticated at the proxy, none of theusers having access credentials for the target, and tracking the accessand activity (communications) of each user.

In a third non-limiting example, a user requires connection to a targetsystem that only accepts a username/password combination as valid targetaccess credentials. However, the user prefers (or is required byorganizational regulations, or in order to enforce new, strongerauthentication methods such as biometrics for control access to oldertarget systems which do not support such methods by themselves) to use adifferent method of authentication, such as biometric identifier,gesture, selecting an image, physical token, certificates, machine ordevice identifier, application identifier etc. The invention can supportthis scenario by the user authenticating to the proxy system using thepreferred method of authentication thus establishing a connection to theproxy. The proxy system then generates a second access request includingthe required target access credentials, establishing a connection to thetarget system.

The choices used to assist in the description of this embodiment shouldnot detract from the validity and utility of the invention. It isforeseen that more general choices including, but not limited to,materials and polarizations can be used, depending on the application.

The use of simplified calculations to assist in the description of thisembodiment should not detract from the utility and basic advantages ofthe invention.

Note that a variety of implementations for modules and processing arepossible, depending on the application. Modules are preferablyimplemented in software, but can also be implemented in hardware andfirmware, on a single processor or distributed processors, at one ormore locations.

The above-described module functions can be combined and implemented asfewer modules or separated into sub-functions and implemented as alarger number of modules. Based on the above description, one skilled inthe art will be able to design an implementation for a specificapplication.

To the extent that the appended claims have been drafted withoutmultiple dependencies, this has been done only to accommodate formalrequirements in jurisdictions that do not allow such multipledependencies. It should be noted that all possible combinations offeatures that would be implied by rendering the claims multiplydependent are explicitly envisaged and should be considered part of theinvention.

It should be noted that the above-described examples, numbers used, andexemplary calculations are to assist in the description of thisembodiment. Inadvertent typographical and mathematical errors do notdetract from the utility and basic advantages of the invention.

It will be appreciated that the above descriptions are intended only toserve as examples, and that many other embodiments are possible withinthe scope of the present invention as defined in the appended claims.

What is claimed is: 1-18. (canceled)
 19. A method of authenticationcomprising the steps of: (a) receiving at a proxy an access request,wherein said receiving is via a native protocol and said access requestincludes client credentials associated with a user; (b) providing targetaccess credentials, wherein said providing is based on said accessrequest, said client credentials, and target authentication information;and (c) sending via said native protocol said target access credentialsto a target; wherein said target access credentials are other than saidclient credentials, and said target access credentials are shared orprivileged credentials.
 20. The method of claim 19 wherein saidreceiving is from a client
 21. The method of claim 19 wherein saidproviding is contingent on successfully verifying the user based on saidclient credentials.
 22. The method of claim 19 wherein said clientcredentials are selected from the group consisting of: (a) a null set;and (b) inherent client credentials.
 23. The method of claim 19 whereinsaid providing of said target access credentials is based on one or morecommunication features selected from the group including: (a)communication content; (b) access request time, (c) client identity, (d)target identity, (e) user identity; (f) access request time; (g)communication time; (h) communication protocol; (i) communicationsettings; and (j) combinations of said communication features.
 24. Themethod of claim 19 wherein said target authentication information isprovided by: (a) a database; or (b) an algorithm; or (c) a privilegedaccess management system (PAMS).
 25. The method of claim 19 wherein aprivileged access management solution (PAMS) performs one or more stepsselected from the group consisting of: (a) authenticating said clientcredentials; (b) providing said target access credentials; (c) storingmonitoring information; (d) storing analysis information; (e) monitoringclient communications from a client to said target; and (f) monitoringtarget communications from said target to said client.
 26. The method ofclaim 19 further comprising the step of: (d) if said target successfullyverifies said target access credentials then authorizing communicationsbetween a client and said target via said proxy.
 27. The method of claim19 further comprising: (d) if said target successfully verifies saidtarget access credentials then said proxy transferring clientcommunications from a client to said target and transferring targetcommunications from said target to said client.
 28. The method of claim27 further comprising at least one-step selected from the groupconsisting of (e) monitoring said client communications and said targetcommunications; and (f) recording said client communications and saidtarget communications.
 29. The method of claim 28 wherein saidmonitoring and said recording are of one or more communication featuresselected from the group consisting of: (i) a communication content; (ii)a target identity; (iii) a client identity; (iv) a user identity; (v) acommunication time; (vi) communication protocol; and (vii) communicationmetadata.
 30. The method of claim 28 further comprising the step of: (g)upon detecting a suspicious activity, initiating an alert.
 31. Themethod of claim 30 further comprising the step of: (h) upon receiving analert, terminating said transferring client communications andterminating said transferring target communications.
 32. The method ofclaim 27 further comprising one or more steps selected from the groupconsisting of: (e) interfering with said target communications; and (f)interfering with said client communications.
 33. The method of claim 32wherein said interfering is selected from at least one of: (i) deletingtarget communications; (ii) masking target communications; (iii)replacing target communications; (iv) deleting client communications;(v) masking client communications; and (vi) replacing clientcommunications.
 34. The method of claim 19 wherein a form of said clientcredentials and a form of said target access credentials are eachselected from the group consisting of: (i) username, (ii) password,(iii) access key, (iv) credential file, (v) biometric identifier, (vi)gesture, (vii) selecting an image, (viii) physical token, (ix)certificates, (x) machine or device identifier, (xi) applicationidentifier, and (xii) combinations of forms of credentials.
 35. A systemfor authentication comprising: (a) a proxy configured to: (i) receive anaccess request, wherein said receiving is via a native protocol and saidaccess request includes client credentials associated with a user; (ii)provide target access credentials based on said access request, saidclient credentials and target authentication information; and (iii) sendvia said native protocol said target access credentials to a target;wherein said target access credentials are other than said clientcredentials, and said target access credentials are shared or privilegedcredentials.
 36. The system of claim 35 wherein said access request isreceived from a client.
 37. The system of claim 35 further including aprivileged access management solution (PAMS) configured to perform oneor more functions selected from the group consisting of: (a)authenticating said client credentials; (b) providing said target accesscredentials; (c) storing monitoring information; (d) storing analysisinformation; (e) monitoring client communications from a client to saidtarget; and (f) monitoring target communications from said target tosaid client.
 38. The system of claim 35 further including one or moremodules selected from the group consisting of: (b) a monitoring moduleconfigured for monitoring: (i) client communications from a client tosaid target; and (ii) target communications from said target to saidclient; and (c) a recording module configured for recording: (i) saidclient communications; and (ii) said target communications.
 39. Thesystem of claim 35 further including a filtering module configured toimplement one or more controls selected from the group consisting of:(a) interfering with client communications from a client to said target;and (b) interfering with target communications from said target to saidclient.
 40. A computer-readable storage medium having embedded thereoncomputer-readable code for authenticating, the computer-readable codecomprising program code for: (a) receiving at a proxy an access request,wherein said receiving is via a native protocol and said access requestincludes client credentials associated with a user; (b) providing targetaccess credentials, wherein said providing is based on said accessrequest, said client credentials, and target authentication information;and (c) sending via said native protocol said target access credentialsto a target; wherein said target access credentials are other than saidclient credentials, and said target access credentials are shared orprivileged credentials.